本課題では全世界の気象データ (2021 年の最低温度) を用いて，その変化をアニメーション (映像) で表した．元々のアイディアは気象データと標高データを組合せ， 3D シーンを生成して標高と温度 (あるいは降水量やその他の気象パラメータ) の関係を表すことだったが，それが意外にも困難であることに気づき，気象データのみを扱うことに向き先を変えた．このような作業は一見簡単に見えるが，後ほど述べる様々な理由で実はそう簡単なものでなかった．本文ではデータの取得からアニメーションの生成まで，地理的研究及び R に関する経験が実質ない状態から本課題の結果を出すまでの流れについて筆者の主観を含めて執筆した．
地理データを何かしらの形で「表現」することは，普段なかなか想像し難い数理的，物理的な関係をわかりやすく説明することができ，また探索的データ解析の一種として新しいパターンを探すのにとても便利な作業だと思われる．例えば前者に関しては台風や雨雲の動きを地図上に載せて，どの地域でいつ雨が降るかを天気予報で解説するなどが良い例であろう．
こういったように「データ」と「地図」を組みわせるのは一見簡単に見えるが，工学的な意味で実はそう簡単でもない．というのは，次の 2 つの問題を先に解決する必要があるからである．
上述したようにこのような問題は理論的ではなく工学的に難しい．つまり 2 つの問題とも解決自体は可能であるが，そこにどれだけの手間を掛けるか，どうすれば手間が減るかなどが解決しづらい部分であると思われる．本文では主にこの 2 つの問題について，具体的な作業の例を用いて筆者の主観に基づいて議論していく．
上述の通り本文は筆者の主観を含めたものである．この主観というのを一言でまとめると次の主張である．
こういう作業はもっと簡単にできるはずなのに膨大な手間をかけなければならないのはおかしい．
なぜそう思ったかについては後ほど詳しく述べるが，簡単に言うとデータの取得があまりにも面倒であるのと， R というエコーシステムがあまりにも使いづらいのが根本の理由である．主観なだけにこの主張に賛同しない人が一定数いるのは筆者も当然承知している．もっと言えば，ダメ出しだけ言っておいて解決を提案しないというのも恐らく批判を招くだろう．しかし，本文で掲げる問題点は一人の人間が解決できるものではない．むしろ関わっている人の大半が問題を把握し，協力しながらより優れた解決を生み出すのが理想の流れである．他方で筆者は地理情報を良く扱う人間ではないので，地理情報に関わる問題を解決する動機がさほど高くない．それでは動機がないのになぜここまでして問題があることを主張するかというと，筆者が普段ソフトウェア開発を行っており，一時的とはいえ地理情報処理に触れた一開発者として，自分が直接その恩恵を受けなくてもより良いソフトウェアの開発を促進したいからである．
この主観の土台として筆者についても簡潔に紹介する．筆者は中学校時代から趣味でプログラミングをしており，普段から身の回りの問題をコンピュータの力で解決してきた者である．自分の携帯電話の通信を効率化するアプリだったり，自分の家計を管理するためのアプリだったり，自分の旅行歴を表示するアプリだったり，「不便」だと思ったことをもっと便利にするために色々と作ってきた者である．また，本文執筆時点では 5 年間の業務経験を持っており，直近 2 年は某大手 IT 企業でアルバイトしながらインフラの基盤となるプロジェクトを傘下に持っている．
第 2 節では本課題の内容及び実装方法について紹介する．第 3 節では課題で遭遇した問題を個別に取り上げ，それらのどこが問題でどのように解決できるかを紹介し，第 4 節では結論を以て本文を終える．
本課題では 2021 年の全世界の最低温度データをアニメーション (冒頭の映像) にした．使用したデータセットは National Oceanic and Atmospheric Administration (NOAA) から取得したもので，2021 年各日の最低気温を 0.5 度の精度で収録したものである 1．
映像の作成は主に次のステップに分けて行った．
データ加工及び PNG 出力は R で行い，詳細なコードを generate-frames.R に記載した．また， ffmpeg による動画生成コマンドは mkvid.sh に記載した．
Abstract で述べたように本課題の元々のアイディアは標高データと気象データを組合せて 3D シーンを作成することだった．そこまでは今回実装していないが，その意図について少しだけ紹介しておく．序論で述べたように何かしらの「データ」を「地図」上に表現することによってイメージしづらい内容をわかりやすく表すことができると考えられる．今回のアイディアでは標高で立体的に作った地図に，色として平均気温を表現することだった．その理由は「温度」と「地形」の関係を表したいところにあり，日本で言うと例えばなぜ北陸地方は寒くて雪がたくさん降るのに関東はさほど寒くなく雪もあまり降らないのか，といった現象を視覚的に表したいと筆者が思った．また気温意外にも例えば降水量や湿度など同じように立体的な地図上に表すことで，なんとなく知られている現象を表すだけでなく，あわよくば未知の現象についても何か得られるものはあるのではないかと思われる．
本課題において Abstract で述べた元々のアイディア (標高データと気象データを組み合わせること) を実現するためのデータ検索も踏まえて，筆者がまず思ったのはデータの取得があまりにも複雑であることだ．データセットを提供する機関は様々あり，それぞれがまた様々なデータを提供しているのは理に適った話であるが，そこでユーザー (ここでは筆者) がほしいデータがあるかどうか，取得できるかどうかというのが機関によってかなりわかりづらいと思われる．ユーザーとして知りたいことは少なくとも以下の項目で，それらの答えをなるべく早く，簡単に見つけたいわけである．
例えば，標高データとして筆者は ASTER Global Digital Elevation Map というデータセットを取得したかった．しかし，「取得できる」という宣言が書かれたブログやらホームページやらを何回も見た挙句，結局どこで取得すればが理解できなかった．また， NASA の Earthdata というツールに確かに ASTER らしきものは載っていたが，それも結局全世界単位でダウンロードできるかどうかなど分からないまま放置することにした．
この問題をもっと抽象的に考えてみると，「ユーザーがほしいデータ」と「提供機関が提供しているデータ」の相違に問題が生まれると考えられる． 後々から気付いたことだが，ASTER の例で言うと恐らく元のデータセットが大きすぎて個人でダウンロードできるレベルではないだろうから部分的に提供していると考えられるが，それをどこか名言してくれればユーザーも無駄に悩むことはないだろう．
データを取得できても地図を描写するのに何かしらの加工をしなければならない．データの読み込みから画像や映像の作成までの過程である程度の作業量が発生するのはごく自然であるが，その作業を如何に減らせるかがいわゆる工学という分野の根本にある．筆者は一技術者として今回主張したいのは， R というエコシステムが一見簡単に見えて実はとても使いづらいということである．その使いづらさがどこにあるのかというと，主に以下の 2 種類に分かれる．
以降はそれぞれについて個別に取り上げる．筆者は様々な言語を経験しているが，業務を含め日常的に一番良く使うのは Python なので，その背景を踏まえてここでは所々 Python と比較しながら議論していく．また筆者が R を使った経験が以前ほとんど無く，今回の課題が初めてなのでいわゆる「初心者」目線も多少なりとも含めて意見を述べる．
「R はだめだ」のような主張から R 言語そのものが嫌いだと思われそうだが，実は言語に (そして言語のみに限って) は，少なくとも筆者目線ではそこまでの致命的な問題は見えなかった．とはいえ問題が全く見えていないわけでもなく，具体的に次の点がかなりのわかりづらさを招くように思われる．
plotとは具体的に何をする関数ですか？
この問いの答えを考えたり探したりするのが，今回の課題で一番時間を費やした問題かもしれない． plot というのは，単純な 2 次データセットを入れると散布図を描いたりライン図を描いたりし，「地理データ」が入っている (であろう) データセットに対しいきなり地図を描く関数である．まずこの事実を一度真剣に考えて頂きたい．
R 経験者 (具体的には generic 関数のことを知っており，その挙動に慣れている人) ならばここで躓くことはないかもしれないが，初心者もしくは他の言語をある程度知っている人から見てこのような挙動をまともに把握するにはそれなりの時間がかかるはずである．少なくとも筆者は新しい言語やライブラリに触れるとき，まず真っ先に問いかけるのは「〇〇は何をするものか？」という質問である．関数ならば「A を渡したら B が返ってきたから， C を渡せばきっと D が返ってくる」という直感をなるべく早く育てるためにもこのような疑問を持つのは正しいと思われる．しかし， R における generic 関数の挙動を知るには関数の名前ではなく，裏で操作している型を知らなくてはだめで，いくら他の言語を知っていても最初からコードの中に登場するデータ型を全部把握するのは簡単な話ではない．ましてや「型を把握していないと先に進めない」という発想を得るまでがそもそも長いのである．
この問題は generic 関数という概念そのものだけでなく， R のライブラリなどにも影響される．というのは，ライブラリで明確な説明と色々な使い方を含めた例文コードを載せてくれればだいぶ理解しやすくなるが，Raster に対する plot のドキュメンテーションを見ても理解しやすいとは思えない．他方で matplotlib.pyplot.plot ではいくらでも親切に解説してくれる上に「この関数は◯である引数を受けて△という動作をし，□である返値を返す」と関数の定義と挙動の明確な説明も当然書かれている．とはいえ matplotlib.pyplot.plot は generic ではないので完全な比較にはならないが，例えば Haskell の Type class 2 なんかであれば，型が常に見えて例文も豊富で何より名付け方が明確なのでかなり理解しやすいものに思われる．ちなみに， Haskell に関しては基本的にドキュメンテーションが雑というのが有名な難点であるが，そう言われる Haskell でも R よりはわかりやすいと筆者は思う．
rotateとはどのパッケージの関数ですか？
この質問の答えを得るにはそこまでの時間は必要ない (なかった) が，それでも厄介な問題に思われる．何が厄介かというと，自分自身が書いたコードについてはパッケージ名を付けて明確に呼び出せば良いだけの話だが，そうしない人が書いたコード見るときにはかなりの頭痛を及ぼす事象だと思われる．「コード」というのは，動けば良いだけの落書きではなく，他の人が (数カ月，数年後の自分自身も含め) 見ても苦労するなく理解できるように書かなければならない．どこかに公開されているようなコードならなおさらそうだ．そして残念ながら R に関してはネットで見かけるたいていの記事や例文コード等は，冒頭にパッケージをたくさん読み込んで，「後は見れば分かるでしょう」という適当な気持ちで書かれているようにしか思わない．これが本当に初心者にとって良い状態なのか？少なくとも R 初心者から出発した筆者はそう思わない．
上記でも述べた通り，コードは動けば良いだけだけでなく，他の人が読んで理解できるように書くべきものであると筆者は思っているし，知っている限りでは大体の開発者も同じスタンスでいる．そしてライブラリ (＝多くの知らぬ人達が使うもの) に関しては特にそれが重要だと思う．しかし，今回の経験範囲で言うと R のライブラリは一見使いやすそうに見えるが，ちょっと変わったことをしようとするどうすれば良いのか一気にわからなくなる．
筆者がこの問題に遭遇したのは動画を生成しようとしたときである．生成しようとした動画は 365 枚のおよそ 3000x1500 のフレームで， FPS 30 で流すと 12 秒ほどの長さしかないものである．そこでなんとか tmap を使ったアニメーションの生成方法 を実装してみたが，実行しようとするとコンピュータのメモリを全部食われた挙句に R が最終的に落ちるという始末．参考までに単純計算をすると 365 枚の RGB 画像は 1 GB 強のメモリしか必要としないはずであるが，tmap を使うとなぜか 16 GB ある筆者のコンピュータの性能が足りないという結果になる．他にも， 3D 曲面を描写しようとしたときや ggplot2 で動画を生成しようとしたときなども同じで，一番自明な usecase に関する例はいくらでもあったが，「どうすればこのライブラリをいじくれるか」という情報はあまり見つからず，結局やりたいことをやるのをやめた訳である．
上記が難点に感じるのは様々な理由があり，その内の一つが筆者の経験であることは否定しない．しかし，例えば leaflet.js なんかと比べると，拡張性は遥かに違うように思う．筆者は leaflet.js を一度使ったことがあり，そのとき初めて触れたのにも関わらず 1~2 時間でかなり自由に扱うことができた．それがなぜかというと， leaflet.js は非常にオープンな構成になっていて，「〇〇と書けば△△という結果が出る」という因果の流れが非常にわかりやすいかつわかりやすく説明されているからだと思われる．他方で ggplot2 の例文コードは，慣れていればともかく最初に見る時に疑問しか出なかった (なぜ+？+は何をするもの？順番は関係あるのか？など)．
本文においていかにも「R は嫌いだ」という印象が強いのは筆者も承知の上である．実際に正直に言うとできるものならもう一生 R に触れたくないというのが本音である．しかし，だからといって R に全くメリットがないと思っているわけではない．調べてみると，統計学等のパッケージは R の方が充実していたり，一回慣れれば (大前提ではあるが) R でやった方が楽な仕事もあるという主張は無視できない．しかし，世の中が一般的にやりたいことではなく，今回の 3D シーンのように自分が特別にやりたいことを考えると，少なくとも筆者は R を極力避けたいと思う．なぜなら Python やその他の汎用言語の方がいじくり安く，「加工」しやすいからである．余談を言うと， 3D シーンを諦める直前では Python で実装された 3D ゲーム作成用のライブラリでも使えばまだ楽だろうと思いながら一瞬だけその方法を試みたが，今度は地理データを上手く操作するために GDAL を Python 環境に入れなければならなく，結果的に時間の都合で諦めたのである．
そしてここで最後にもう一つだけ述べる．上述の問題点は確かに慣れればある程度解決でき，R でも効率良く作業ができるであろう．もっと言えば今回の課題も時間をかければ元のアイディアを実装できたであろう．しかし，残念ながら筆者自身の研究やその他の人生の課題がある中でそこまでの時間をかけることは非現実的に思う．もっとやりやすいテーマを選べば楽に済んだことでもあるが，今となってはそれは意義のない議論になってしまう．だからこそ最後に主張しておきたいのが，地理データを扱うこと自体を問題視していないということである．データを使って 3D シーンを描くというアイディアは今度手が空いたときのネタにでもして，今回の課題はこれを以て終了とする．
「地理データ」で遊ぶ可能性は無限にあると思うのですが，今回の課題は「地理データで遊ぶ」というより「R と戦う」要素が強すぎて本当に疲れました．もっとも，変に難しいことをしようとして中途半端なところで終わらせる自分も悪いですが．．． データを扱うのにある程度の技術 (R にしろ Python にしろその他にしろ) が必要なのはわかりますが，たった 2 単位分の授業で R を覚えてある程度自由に遊べるようになるのは恐らく無理な気がします (友達もそれなりに戦ってたので)．なので具体的な形はともあれ，今度はコードの実装からもうちょっと離れた，「こういうデータがあればこういうことができたりするよ」というような形で授業をするともっと面白いと思います．あとは，返って課題の範囲をある程度簡単な実装に絞るとコード以外のところに集中できるかなと思います．とにかく私が嫌いなのはあくまでも R だけで，地理データはわりと面白かったです．結びで書いた通り 3D シーンは今度暇な時に真面目にやってみたいのでそのときにまた頑張ります．
長文ですみませんでした！
https://psl.noaa.gov/thredds/catalog/Datasets/cpc_global_temp/catalog.html?dataset=Datasets/cpc_global_temp/tmin.2021.nc↩︎
Haskell において Type class とは generic 関数を定義するための手段として考えることができる．↩︎